AWS Systems Manager で EC2 のバックアップを取得（期日指定篇）
AWS Systems Manager には「メンテナンスウィンドウ（メンテナンス時間、Maintenance Windows）」という、設定した時間（ウインドウ）に設定したタスクを実行させる機能があります。
前の記事 で作成したドキュメント（AWS Systems Manager ドキュメント）「CM-BackupEC2Instance」を使用して、期日指定でバックアップ（AMI 取得）するタスクを組んでみました。
なお公式ドキュメントの日本語訳は、当記事執筆時点で若干古い記述が残っていたので、この記事では原則英語版の URL を記載します。言語の切替は出来るので、実際に作業される場合は切り替えつつ参照して下さい。
ドキュメント「CM-BackupEC2Instance」については下記記事を参照してください。
準備
メンテナンスウィンドウでタスクを自動実行させる場合、タスクを作成する前にいくつか準備が必要です。
- ターゲットとなるEC2インスタンスにて SSM を有効にする
- SSM エージェントのインストール
- IAM ロールに特定権限の付与
- マネージドインスタンスとして AWS Systems Manager に登録する
- AWS Systems Manager が自動実行に使用する IAM ロールの作成
このうち SSM エージェントのインストールについては、今の Amazon Linux は最初から有効になっているため説明は割愛します。他ディストリビューションなどでインストールから始める場合は、下記ドキュメントを参照して下さい。
ターゲットインスタンスの準備
自動実行タスクの対象（ターゲット）に指定する EC2 インスタンスはマネージドインスタンス、つまり、SSM エージェントが導入されて AWS Systems Manager から認識されている状態で無ければなりません。
今回は AMI の取得なので、Run Command などは使わないのですが、現時点ではそのような仕様のようです。
現在マネージドインスタンスとして認識されているインスタンスは、AWS Systems Manager コンソールの「Managed Instances」（あるいは EC2 コンソールの「マネージドインスタンス」）を参照することで確認できます。
とはいえそんなに難しい話ではないので、さくっと終わらせます。対象の EC2 インスタンスに IAM ロールが割り当てられているなら、該当のロールに下記の手順でポリシーを割り当て（アタッチ）して下さい。
- マネジメントコンソールにて EC2 のコンソールを開く
- バックアップの対象にしたいインスタンスの「説明」を開き、「IAM ロール」の欄に表示されているロールの名前（リンク）をクリックする
- 「アクセス権限」タブを開き、「ポリシーのアタッチ」をクリック
- 「AmazonEC2RoleforSSM」を探してチェックを入れ、「ポリシーのアタッチ」をクリックする
現状で IAM ロールが割り当てられていない場合は、新規に IAM ロールを作成して上述の「AmazonEC2RoleforSSM」をアタッチし、EC2 インスタンスに割り当てて下さい。
SSM エージェントが HealthCheck に成功すると、上述のコンソールに自動的に登録されます。該当インスタンスの /var/log/amazon/ssm/amazon-ssm-agent.log ログファイルを眺めつつしばらく（数分〜十数分程度）待ってみて下さい。
あるいは該当 EC2 インスタンスを再起動（OS再起動）すると、起動後すぐに反映されます。再起動が可能であればそれでもよいでしょう。
AWS Systems Manager 用の IAM ロール作成
AWS Systems Manager がタスクを実行する際に必要となる IAM ロールを作成します。
- 下記ドキュメントに従って IAM ロールを作成する
- Controlling Access to Maintenance Windows - AWS Systems Manager
- 作成した IAM ロールに対して、実行するタスクにあわせて権限を付与（ポリシーをアタッチ）する
まずは IAM ロールを作成します。ちょっと手順が複雑ですが…
- マネジメントコンソールの IAM コンソールを開く
- サイドペイン「ロール」から「ロールの作成」をクリック
- 「信頼されたエンティティの種類を選択」の画面で、「AWS サービス」->「EC2」をクリック、ユースケースとして「EC2」を選択して次へ進みます
- AmazonSSMMaintenanceWindowRole にチェックをいれて次へ
- ロール名に任意の名前をいれます。分かりやすい名前が良いでしょう。ここでは cmws-asm-maintenancewindow-role としました
- 必要に応じて「ロールの説明」を修正し「ロールの作成」をクリックします
- いま作成したロールを一覧から探して、ロール名の部分のリンクをクリック
- 「信頼関係」のタブを開き「信頼関係の編集」をクリック
- 「信頼関係の編集」画面で、ポリシードキュメントの JSON を全て後述する内容に置き換えます
- 「信頼ポリシーの更新」をクリック
手順 9 で置き換えるポリシードキュメントはこちらで、要は Service に2行追加したかたちになります。
{
"Version":"2012-10-17",
"Statement":[
{
"Sid":"",
"Effect":"Allow",
"Principal":{
"Service":[
"ec2.amazonaws.com",
"ssm.amazonaws.com",
"sns.amazonaws.com"
]
},
"Action":"sts:AssumeRole"
}
]
}
なお、SNS 通知を行う場合はもう少し手順が必要ですが、今回は不要なので割愛します。
続けて必要なポリシーをアタッチします。今回はAmazonEC2FullAccessを付与しました。
以上で、メンテナンスウィンドウを使う上での準備は整いました。
メンテナンスウィンドウの作成
いよいよ AWS Systems Manager でメンテナンスウィンドウを作成します。
今回は下記の内容で作成しました。
- 12/30 (土) 23:00 (JST) からバックアップ開始
- 対象（ターゲット）は上述の 3インスタンス
- タスクには こちら で作成した「 CM-BackupEC2Instance 」ドキュメントを使用
メンテナンスウィンドウの作成
まずマネジメントコンソールから AWS Systems Manager コンソールを開き、「Maintenance Windows」から「メンテナンスウィンドウの作成」をクリックします。
- 名前を入力します。使用できるのは a～z、A～Z、0～9 の英数字とピリオド (.)、下線 (_)、ハイフン (-) の記号のみとなります
- 「未登録ターゲットを許可」のチェックボックスは、今回はターゲットを指定するため外して（OFF）おいてください
- スケジュールを CRON 式で指定します。今回は「12/30 (土) 23:00 (JST) 」が目的なので、下記のように設定しました
cron(0 14 30 12 ? 2017)- 「期間」は 1〜24（時間）で指定する必要があるので、とりあえず 1 とします
- 「タスクの開始を停止」は 0 にしました
CRON 式の書式は CloudWatch Events と同じです。詳細は下記ドキュメントをご覧下さい。
個人的には UTC で指定しなくてはならないところと、「日を指定したら曜日は『 ? 』にしなくてはならない（あるいはその逆）」というところが、気をつける必要のあるところかと思いました。
内容に問題がなければ「メンテナンスウィンドウの作成」をクリックして下さい。作成リクエストが成功したら、下記のような画面になります。
ターゲット（EC2 インスタンス）の登録
メンテナンスウィンドウという「枠」が出来たら、そこにターゲットとタスクを追加します。
まずはターゲットということで、作ったばかりの「CM-EC2-maintenance-backup_20171230」メンテナンスウィンドウを選択し、アクションから「ターゲットの登録」をクリックします。
ターゲットの名前などは省略可能なので、今回は取りあえず空欄のままで。
ターゲットの選択方法は 2通りがありますが、今回は「インスタンスの手動選択」を行います。
上で設定したマネージドインスタンスがリスト表示されるので、バックアップの必要なインスタンスを選択してください。今回は全て選択しました。
選択したら「ターゲットの登録」をクリックします。
タスク（オートメーションタスク）の登録
続いてタスクを登録します。
同じくアクションから「オートメーションタスクの登録」を選択して下さい。
ターゲットと同じく名前は省略します。
オートメーションドキュメントとして、こちら で作成した「 CM-BackupEC2Instance 」を一覧から探して選択して下さい。自作のドキュメントが少ない段階では、フィルタ欄で「所有者」>「自己所有」を選択しておくと見つけやすいかと思います。
ターゲットとしては、先ほど作成したターゲットを指定します。現在ひとつしか作っていないので、表示されているものを選択してください。
レート制御はお好みですが、AMI 取得による バックアップは特に負荷が上がるわけでもないので、今回は 3 台同時に実行するよう設定してみます。
ロールには、上で作成した IAM ロール「cmws-asm-maintenancewindow-role」を指定します。
入力パラメータの欄ですが、ここには「{{ TARGET_ID }}」と記述します。これにより、CM-BackupEC2Instance の InstanceId には今回登録したターゲット（EC2 インスタンス）のインスタンス ID が入力されていきます。
このあたりの指定方法（何が指定できるか）は、下記のドキュメントの「Common parameters for task-invocation-parameters」に書いてありますのでご一読ください。
TARGET_ID: ターゲットの ID。ターゲットタイプがインスタンス (現在唯一サポートされているタイプ) の場合、ターゲット ID はインスタンス ID です。
問題なければ「オートメーションタスクの登録」をクリックします。
＊ ＊ ＊
以上で準備完了です。安心して大晦日をお待ち下さい。
試験
・・・というのも不用心すぎて不安になるので、いちど時間指定を変更して試してみます。
「編集」と書かれたボタンを押してメンテナンスウィンドウの設定変更画面にうつり、CRON/Rate式の指定を下記に変更しました。
cron(0 0 29 12 ? 2017)
日本時間の 2017/12/29 09:00 に実行されるはずです。待ちましょう。
・・・うまく動作したようで、「履歴」の欄に実行内容が記録されました。
EC2 インスタンスのコンソールから、AMI が正常に作成されていることも確認できました。
試験が終わったら、忘れずに日時指定を戻しておきましょう。
今後のために
以上のように、いちど作成したメンテナンスウィンドウは残しておいて、後日別のメンテナンスの時に使うことが可能です（名前も修正可能です）。
ただ、使っていない時は「有効」になっているのも気持ち悪いので、アクションから「メンテナンスウィンドウを無効にする」としておくと良いかと思います。
所感
「定期的に EC2 のバックアップ（AMI）を取得する」という目的のためにはいろいろな方法があります。おそらく日常的にバックアップを取りたいのであれば、例えば他記事で紹介している下記のような方法を使った方が良いでしょう。
Lambda ファンクションを記述して CloudWatch Events から起動する方法も珍しくないかと。
これらに比べて今回ご紹介した方法では、取得した AMI の世代管理・古い AMI を自動的に削除するという機能がない一方で、下記のような特徴があるかと思います。
- AWS Systems Manager だけで完結する
- ターゲット（EC2 インスタンス）が明確、変更も容易
- 実行の証跡が残せる
- 「承認を得て実行」という動作への改造も容易
個人的には完全に自動化する局面ではなく、いわゆる運用（オペレーション）業務として利用する場合に使いやすいのではと感じました。
一方で、必ず SSM エージェントを導入する必要があるというところで、使いどころが限定されることもあります。うまく使い分けていきたいと思います。
![[アップデート] Amazon QuickSight へロゴやテーマカラーを設定するための「ブランド管理機能」が追加されました](https://images.ctfassets.net/ct0aopd36mqt/wp-thumbnail-19e77b9a51519e08b94d0f688c125729/4f439c75e1ee56c70e315fa46fa45f81/amazon-quicksight)
